PCT/EP2004/051957 / 2 003P13487WOUS 




Method for supporting the Name Delivery feature for mixed TDM 
networks/ SIP CENTREX communication architectures. 

The invention relates to a method in accordance with the 
5 preamble of claim 1. More recent communication architectures 
provide for the separation of call-processing networks in 
communication service related units and the transport of the 
payload (Bearer Control) . This results in a decomposition/ 
separation of call set-up and medium or bearer set-up. The 

10 payload can be transmitted (through-connection of the traffic 
channel) via different high bit rate transport technologies 
such as, for example, ATM, IP, Frame Relay. With a separation 
of this type, the telecommunication services* currently used in 
narrow band networks can also be realized in broadband 

15 networks. Thereby the subscribers are connected either 

directly (e.g. via a DSS1 protocol) or via exchanges designed 
as Media Gateway Controllers (MGC) (e.g. via the ISUP 
protocol) . The payload itself is converted by the Media 
Gateways (MG) used in the respective transport technology. The 

20 Media Gateways are controlled by respectively allocated Media 
Gateway Controllers (MGC) . The Media Gateway Controllers use 
the standard protocols, such as, for example, the MGCP 
protocol or the H.248 protocol to control the Media Gateways. 
In order to communicate between each other, the Media Gateway 

25 Controllers use an ITU standardized BICC (Bearer Independent 
Call Control) protocol, which is a further development of an 
ISUP protocol. The BICC protocol is formed from several 
standardized protocols and thus comprises a protocol family. 

30 At the IETF committee on standardization, protocols suitable 
for the BICC protocol emerged with the SIP and SIP-T 
protocols. The s'lP-T protocol (RFC 3204) represents an 
addition to the SIP protocol (RFC 3261) . Using the SIP-T 
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protocol, it is possible to transmit ISUP messages - in 
contrast to with SIP protocol. In general ISUP messages are 
transmitted by means of tunnels, i.e. by transparent split-lot 
transfer. Preferably the ISUP-messages issued by a PSTN 
5 subscriber are held and supplied to the receiving PSTN 

subscriber together with a bearer message (INFO Method, RFC 
2976) . A general network configuration with TDM -/ IP networks 
of this type is shown in Fig. .1. Here, by way of example, 2 
PSTN networks are shown and in each respective network there 

10 are several PSTN subscribers arranged in the usual manner. 

These are connected to the local exchanges, LE, which are, in 
turn; connected to the transit exchanges, TX. In the transit 
exchanges, TX, the separation is now made between signaling 
information and payload. The transit exchange TX supplies the* 

15 signaling information directly via an ISUP protocol to a 

respectively allocated Media Gateway Controller MGC (the A or 
B side) . The payload is transmitted to a Media Gateway MG 
(arranged at the input side) (the A or B side), that functions 
as an interface between TDM network and an ATM or IP 

20 transmission network, where it is transmitted in packet mode 
via the respective transmission network (ATM or IP) . The Media 
Gateway MG of the A side is controlled by the respectively 
allocated Media Gateway Controller MGC of the A side as is the 
Media Gateway MG of the B side by the Media Gateway Controller 

25 MGC of the B-side allocated to. In the event that the payload 
is transmitted from Media Gateway MG of the A side to the 
Media Gateway MG of the B side, then again under the control 
of the Media Gateway Controllers MGC of the B side allocated 
to the Media Gateway MG of the B side, said payload is 
-30 converted into a TDM data stream and supplied to the PSTN 

subscriber in question. The data transmitted between the Media 
Gateway Controller MGC and the respectively allocated Media 
Gateway is supported by a standardized protocol. This can be, 
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for example, the MGCP or the H.248 protocol. A BICC protocol 
(or possibly ISUP+ protocol), a SIP or SIP-T protocol can be 
used as standardized protocols between the two Media Gateway 
Controllers MGCs. Further devices such as proxy devices (SIP 
5 world) and/ or CMN exchanges (Call^Mediation Node, I SUP/ BICC 
world) can be switched between the two Media Gateway 
Controllers. In principle, it is desirable that the features 
known from the TDM world can also be used in the IP world. The 
Name Delivery feature, known to traditional (TDM) CENTREX 

10 subscribers, is presented as an example of this. Hereby, under 
a CENTREX (Central Office Exchange) configuration, is to be 
understood a configuration that includes the realization of 
features of a private branch exchange in subscriber exchanges 
in the public network. If the lines of a user group are 

15 connected with each other via CENTREX exchanges - and the public 
-telephone network, one refers to this as a Wide Area CENTREX. 
Potential CENTREX services users are, therefore: 

- groups with frequent change of location. 

20 - large interconnected complexes such as high-rises, technology 
and media centers, airports, 

- groups with decentralized structures which generate heavy 
internal traffic between the different locations. 

25 In addition Fig. 1 shows the connection of a SIP CENTREX 
configuration as made via a SIP proxy server to a Media 
Gateway Controller MGC. The information is exchanged between 
the SIP subscribers of a SIP CENTREX configuration using the 
SIP protocol. All the subscriber related data of the CENTREX 

30 configuration is managed and maintained in the SIP proxy 
server . 

In a configuration of this type according to Fig. 1, there is 
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the problem that in the mixed operation ( Interworking) of TDM 
networks/ IP networks/ SIP CENTREX configurations/ TDM CENTREX 
configurations, it is not possible to use the Name Delivery 
feature for CENTREX configurations known from the TDM world, 
5 as the necessary definitions have not yet been made. 

The object of the invention is to find a way to enable the 
Name Delivery feature also to be used for networks with mixed 
TDM configurations/ SIP CENTREX configurations. 

10 

Based- on the features specified in the preamble of claim 1, 
the object of the invention is achieved by the features 
claimed in the characterizing part. 

15 The advantage of the invention is to be found in the fact that 
when SIP CENTREX configurations are used, any subscriber (SIP 
or traditional TDM subscriber) has the name of the other 
subscriber (Partner) displayed to him/her. A further advantage 
of the invention is to be seen in the fact that the Name . 

20 Delivery feature can also be used without limitation in ISUP/ 
BICC/ H323 networks while interworking with SIP network. 
Thereby, the Name Delivery feature includes the sub-feature 
"Calling Name" (name of the subscriber calling is displayed) 
and also "Connected Name" (name of the subscriber called is 

25 displayed when call taken) . 

Advantageous developments of the invention are specified in 
the subclaims . 



30 



The invention is explained in greater detail below with 
reference to an exemplary embodiment illustrated in a 
figurative manner, in which; 
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Figure 1 shows the relationships between 2 PSTN networks 

between which an Internet network is arranged, and 
with a SIP CENTREX configuration, 

5 Figure 2 shows the connection of a SIP CENTREX configuration 
to an Internet network with the information elements 
necessary to realize the Name Delivery feature 

According to Figure 2 , the invention is explained in more 
10 detail with reference to an exemplary embodiment. It is hereby 
assumed that the subscriber of a TDM network (A side) calls 
the SIP subscriber (B side) of a SIP CENTREX configuration - 
in this case the subscriber SIP B. In this case, the signaling 
connection is routed via a SIP proxy (application server) 
15 server that supports the Name Delivery feature. 

To realize this, first it is necessary to decide on the' 
definitions according to TABLE 1 for the mapping for the 
transition I SUP/ BICC to SIP and vice versa. The mapping is 

20 controlled in the Media Gateway Controller MGC of the B side 
(although the controller functionality is not shown here as 
there is no Media Gateway present, the device MGC of the B 
side is marked as Media Gateway Controller) . As, according to 
prior art (ISUP/ BICC), the Name Delivery feature for TDM 

25 CENTREX configuration is controlled via proprietary solutions, 
the name information is held in different protocol elements of 
the ISUP/ BICC protocol. By way of example, two providers AI, 
A2 are displayed. In the case of Al, the name information is 
held in the ISUP/ BICC protocol element "CallingName" , in the 

30 case of a provider A2 in the ISUP/BICC protocol element "CTX 
coding/ decoding" (APP parameter (application transport 
parameter) based on ITU-T Recommendation Q.765). In the latter 
case, the name information is also held for the sub-feature 
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"Connected Name" . 



Provider 


I SUP/ BICC 


SIP 


Al 


CallingName 


Display field in FROM 
header/ privacy header 


A 2: CTX ASE 
calling name 


CTX 

coding/decoding 


Display field in FROM 
header/ privacy header 


A 2: CTX ASE 
connected name 


CTX 

coding/ decoding 


Display name of the 
CONTACT Header/ 
privacy header 



TABLE 1 



5 According to the invention (TABLE 1, right-hand column) 

provision is made in a first step for the name information for 
the sub-feature "Calling Name", to be transmitted (mapping), 
in principle, into the protocol element of the SIP protocol 
"Display field in FROM header/ privacy header" .In the case of 
10 the sub-feature "Connected Name", the name information should 
be held in the SIP protocol element "Display name of the 
CONTACT Header/ privacy header". 

In a second step, the subsequent actions are displayed in 
15 TABLE 2. The name information is supplied in the SIP protocol 
elements "Display field in FROM header/ privacy header" to the 
proxy server SIP proxy via the SIP "INVITE" message. This 
first checks whether the called subscriber SIP B has allowed 
or applied for the display of the name of the calling 
20 subscriber (chargeable service) . This is possible as the proxy 
server has stored the relevant data for this in a database. 
This can be an internal database in the proxy server ' itself , 
but it can also be externally connected to the proxy server. 



PCT/EP2004/051957 / 2003P13487WOUS 



Information can also be stored in the database about whether 
the calling subscriber . wants his/her name to be displayed or 
not.. If the called subscriber SIP B^does not allow the name of 
the calling subscriber to be displayed, the proxy server 
5 removes the name information from the SIP protocol element 
"Display field in FROM header/ privacy header". 

Otherwise the name display is removed from the database and 
entered into the protocol element "Display field in FROM 
10 header/ privacy header". If the name display is already there, 
then no intervention is made. The nairte information is supplied 
to the called subscriber SIP B in the protocol element 
"Display field in FROM header/ privacy header" and displayed 
on the terminal device. 

15 



SIP 


Proxy server (SIP 
proxy) 

Database query 


SIP 


FROM 

header /privacy 
header 


Is the Name Delivery 
feature (Calling Name) 
desired by called 
subscriber? 


Add or remove 
Display field 
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header 


CONTACT 

Header /privacy 
header 


Is the Name Delivery 
feature (Connected 
Name) desired by called 
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Display name of 
the CONTACT 
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header 



TABLE 2 
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In the following, it is now assumed that the called 
subscriber SIP B accepts the call. The name information of the 
called SIP subscriber SIP B is routed via the SIP handshake 
5 message 200 OK and analyzed in the proxy server. If the name 
display is allowed at the calling subscriber, then said 
information is entered into the SIP protocol element "Display 
name of the CONTACT Header/ privacy header", or removed if the 
display is to be suppressed. 

10 

It should be noted that the invention can also be used if 
there is no ISUP/ BICC protocol between the PSTN subscriber 
(ISDN, analogue subscriber or also mobile communications 
subscriber) and the SIP subscriber. This means that the method 
15 is then carried out within the exchange. The interworking of 
NextGenerationNetwork subscribers such as VoDSL, H323 etc. to 
SIP or SIP-T is thus also possible. 

In the method just described, the method procedures are 
20 separated in the Media Gateway Controller and the proxy. 

server. This separation is, however, not mandatory, the method 
procedure can also take place in a single device. 



